Netware Super Library

home *** CD-ROM | disk | FTP | other *** search

/ Netware Super Library / Netware Super Library.iso / zipfiles / l2o / nsd202.exe / SECURITY.DOC < prev

Wrap

Text File | 1993-01-20 | 30KB | 846 lines

NCP Packet Signature for NetWare v3.11 PATENT PENDING - Novell, Inc. --------------------------------------------------------------------- The software files enclosed in these "zip" files are fixes or patches to legally licensed Novell software and are protected by the copyright laws of the United States and international copyright treaties. This zip file contains software which is designed to replace Novell client software and software which run as NetWare Loadable Modules under the NetWare operating system. You may without charge, reproduce, distribute and use copies of the software for its intended purposes to replace legally obtained Novell software, provided you do not receive any direct payment, commercial benefit, or other consideration for the reproduction, distribution or use, or change or omit any proprietary rights notice appearing on or in the software. This is a personal right. You may not duplicate, distribute or authorize use outside of the legal entity you represent. THE SOFTWARE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, TITLE AND FITNESS FOR A PARTICULAR PURPOSE. TO THE EXTENT YOU USE SOFTWARE, YOU DO SO AT YOUR OWN RISK. IN NO EVENT WILL NOVELL BE LIABLE TO YOU FOR ANY DAMAGES ARISING OUT OF YOUR USE OF OR INABILITY TO USE THE SOFTWARE. Security Enhancement -------------------- In recent weeks, Novell has verified the existence of a threat to NetWare security. The mechanism for intrusion was discovered and documented by students and professors of Lieden University in the Netherlands. After responding to the initial threat with a NetWire release, Novell established an aggressive two-phase strategy to analyze, develop and verify solutions to the broader issues surrounding this threat. The following security enhancement for NetWare v3.11 represents the first phase of Novell's aggressive strategy to analyze and develop solutions that enhance network security. This enhancement consists of NetWare loadable module's, new shell's and various utilities. This SECURITY.DOC file defines the capabilities of the enhancement, the configuration options, the installation of the server and client portions and provides other useful guidelines and tips. This enhancement contains seven self-extracting ZIP files: SECSYS.EXE On diskette SIGNATURE_1 SECDOS.EXE SECOS2.EXE SECUT1.EXE On diskette SIGNATURE_2 SECUT2.EXE SECUT3.EXE On diskette SIGNATURE_3 (Optional: *) SECPRN.EXE * The set of utilities found in SECUT3.EXE are not specifically required for the security enhancement, but contain various fixes and updates. Before installing this enhancement, customers should read through the SECURITY.DOC file to determine if installation of the security enhancement is needed. Particular attention should be given to the section on when to use NCP packet signature. Customers in need of additional support and service should contact their local reseller. The enhancement is being made available free of charge on NetWire and NetWare Express (minimal connection charges apply on NetWire and NetWare Express) or by calling 1 (800) NetWare. How NCP Packet Signature Works ------------------------------ NCP packet signature is an enhanced security feature that protects servers and clients using the NetWare Core Protocol by preventing packet forgery. Without the NCP packet signature installed, it is possible for a network client posing as a more privileged client to send a forged NCP request to a NetWare server. By forging the proper NCP request packet, an intruder could gain SUPERVISOR rights and access to all network resources. NCP packet signature prevents packet forgery by requiring the server and the client to "sign" each NCP packet. The packet signature changes with every packet. NCP packets with incorrect signatures are discarded without breaking the client's connection with the server. However, an alert message about the invalid packet is sent to the error log, the affected client, and the server console. The alert message contains the LOGIN name and the station address of the affected client. A two-part process between the client and the NetWare server determines the NCP packet signature: * At LOGIN, the server and the client determine a shared, secret key known as the session key. * For each request or response packet, the server and the client calculate a signature based on the session key, a "fingerprint" algorithm, and the previous packet's signature. The unique signature is appended to the NCP packet. If NCP packet signature is installed correctly on the server and all of its clients, it is virtually impossible to forge a valid NCP packet. Packet Signature Options ------------------------ Because the packet signature process consumes CPU resources and slows performance, both for the client and the NetWare server, NCP packet signature is optional. Several signature options are available, ranging from never signing NCP packets to always signing NCP packets. NetWare servers have four settable signature levels, and network clients also have four signature levels. The signature options for servers and clients combine to determine the level of NCP packet signature on the network. NOTE: Some combinations of server and client packet signature levels may slow performance. However, low CPU-demand systems may not show any performance degradation. Network supervisors can choose the packet signature level that meets both their performance needs and their security requirements. Server Levels ------------- Server packet signature levels are assigned by a new SET parameter: SET NCP Packet Signature Option = [number] Replace [number] with 0, 1, 2, or 3. The default is 2. Number Explanation --------------------- 0 Server does not sign packets (regardless of the client level) 1 Server signs packets only if the client requests it (client level is 2 or higher) 2 Server signs packets if the client is capable of signing (client level is 1 or higher) 3 Server signs packets and requires all clients to sign packets (or logging in will fail) Client Levels ------------- Client signature levels are assigned by a new NET.CFG parameter: signature level = [number] Replace [number] with 0, 1, 2, or 3. The default is 1. Number Explanation --------------------- 0 Client does not sign packets 1 Client signs packets only if the server requests it (server option is 2 or higher) 2 Client signs packets if the server is capable of signing (server option is 1 or higher) 3 Client signs packets and requires the server to sign packets (or logging in will fail) Effective Packet Signature -------------------------- The packet signature levels for the server and the client interact to create the "effective" packet signature. Some combinations of server and client levels do not allow logging in. The table below shows the interactive relationship between the server packet signature levels and the client signature levels. Effective Packet Signature of Server and Client ----------------------------------------------- IF Server=0 Server=1 Server=2 Server=3 Client=0 No sign No sign No sign No login Client=1 No sign No sign Sign Sign Client=2 No sign Sign Sign Sign Client=3 No login Sign Sign Sign When to Use NCP Packet Signature -------------------------------- NCP packet signature is not required for every installation. Some network supervisors may choose not to use NCP packet signature because they can tolerate certain security risks. Security Risks -------------- The following situations are examples of tolerable risks that may not need NCP packet signature: * Only executable programs reside on the server. * All workstation users on the network are known and trusted by the supervisor. * Data on the NetWare server is not sensitive; loss or corruption of this data will not impact operations. NCP packet signature is recommended for security risks such as: * An untrustworthy user at a workstation on the network. * Easy physical access to the network cabling system. * An unattended, publicly accessible workstation. Signature Level Examples ------------------------ The default NCP packet signature level is 1 for clients and 2 for servers. In most installations, this setting provides the most flexibility while still offering protection from forged packets. Below are some examples of using different signature levels. All Information on the Server Is Sensitive ------------------------------------------ If an intruder gained access to any information on the NetWare server, it could damage the company. The network supervisor sets the server to level 3 and all clients to level 3 for maximum protection. Sensitive and Non-sensitive Information Reside on the Same Server ----------------------------------------------------------------- The NetWare server has a directory for executable programs and a separate directory for corporate finances (such as accounts receivable). The network supervisor sets the server to level 2, and the clients that need access to accounts receivable to level 3. All other clients remain at the default, level 1. Users Often Change Locations and Workstations --------------------------------------------- The network supervisor is uncertain which employees will be using which workstations, and the NetWare server contains some sensitive data. The network supervisor sets the server to level 3. Clients remain at the default, level 1. Workstation is Publicly Accessible ---------------------------------- An unattended workstation is set up for public access to non- sensitive information, but another server on the network contains sensitive information. The network supervisor sets the sensitive server to level 3 and the unattended client to level 0. Installing NCP Packet Signature on the v3.11 Server ---------------------------------------------------- NCP packet signature is installed at the server and at each workstation. This section describes the procedures for the server. To ensure secure connections, NCP packet signature should be installed on all servers on the network. Before installing any new software, make sure you have a complete backup of current SYS:SYSTEM, SYS:PUBLIC and SYS:LOGIN files. Perform these steps to all servers on your network. 1a. Flag *.NLM files in the SYS:SYSTEM directory Shareable, Read Write. 1b. Flag ?CONSOLE.* files in the SYS:SYSTEM directory Shareable, Read Write. 1c. Flag *.* files in the SYS:PUBLIC directory Shareable, Read Write. 1d. Flag LOGIN.EXE file in the SYS:LOGIN directory Shareable, Read Write. 2. Copy the self-extracting ZIP files to the appropriate directory. File Copy to this directory ------------------------------------- SECSYS.EXE SYS:SYSTEM SECUT1.EXE SYS:PUBLIC SECUT2.EXE SYS:PUBLIC SECUT3.EXE SYS:PUBLIC SECPRN.EXE SYS:PUBLIC Note: SECUT3.EXE is optional, but recommended. 3. For each file listed above, change to the appropriate directory and execute the new files. For example, change to the SYSTEM directory and type SECSYS. This unZIPs the files into the current directory. 4. Move LOGIN.EXE file from the SYS:PUBLIC directory to the SYS:LOGIN directory. 5a. Flag *.NLM files in the SYS:SYSTEM directory Shareable, Read Only. 5b. Flag ?CONSOLE.* files in the SYS:SYSTEM directory Shareable, Read Only. 5c. Flag *.* files in the SYS:PUBLIC directory Shareable, Read Only. 5d. Flag LOGIN.EXE file in the SYS:LOGIN directory Shareable, Read Only. 6. You may want to delete the self-extracting ZIP files from SYS:SYSTEM and SYS:PUBLIC at this time. Load PBURST.NLM --------------- Use this procedure to load the PBURST NLM and add the new SET parameters to the NetWare v3.11 server. 1. At the server console, type LOAD PBURST <Enter> 2. To automatically load PBURST.NLM the next time the server boots, insert the "LOAD PBURST" command at the beginning of the AUTOEXEC.NCF file. Assign the Server Packet Signature Option ----------------------------------------- Insert the following SET command in the AUTOEXEC.NCF file immediately below the "LOAD PBURST" command: SET NCP Packet Signature Option = [number] Replace [number] with 0, 1, 2, or 3. The default is 2. Installing NCP Packet Signature on a NetWare v2.x Server -------------------------------------------------------- This section describes the procedure for installing NCP packet signature on a NetWare v2.x server. NOTE: Workstation installation procedures are identical to the NetWare v3.11 procedures. 1. Copy the self-extracting ZIP file, SECSYS.EXE, to the SYS:SYSTEM directory. 2. Change to the SYS:SYSTEM directory and execute the file by typing SECSYS <Enter> 3. Delete the *.NLM files. (These files are not needed for NetWare v2.x.) 4. Flag the SECUREFX.VAP file as Shareable, Read Only by typing FLAG SECUREFX.VAP SRO <Enter> 5. Reboot the server. The following prompt appears: "Value added processes have been defined. Do you wish to load them?" 6. Type Y <Enter> Assigning the Server Signature Level ------------------------------------ The default signature level for the server is 2. To change the level, use the following console command: SIGNATURE LEVEL = number <Enter> Replace "number" with 1, 2, or 3. The default is 2. For signature level 0, either do not put the SECUREFX VAP in SYS:SYSTEM, or reboot the server and answer "no" to the value added processes prompt. NOTE: This last option will not load ANY VAPS. Installing NCP Packet Signature on the DOS and WINDOWS workstations. -------------------------------------------------------------- Copy the SECDOS.EXE self-extracting ZIP file to a work directory on the network or your hardrive. Go to the work directory and type SECDOS [<drive letter>:] This unZIPs the files. New drivers included: --------------------- Some updated ODI drivers have been included. They use Ethernet frame type 802.2 by default.These are: NE1000.COM NE2000.COM NE2.COM NE2_32.COM (NOTE: This driver name replaces the old NE2-32.COM ). To configure these drivers to run Ethernet frame type 802.3 , make the following changes to the NET.CFG file: Add the line FRAME ETHERNET_802.3 into the LINK DRIVER section. DOS Workstations ---------------- Copy the appropriate file to each workstation's boot disk from the work diskette. If the workstation uses Copy this file -------------------------------------------- Conventional memory NETX.EXE Expanded memory EMSNETX.EXE Extended memory XMSNETX.EXE Packet burst BNETX.EXE NOTE: If *NETX.COM files reside in the same directory as *NETX.EXE files, rename or remove the *.COM files to make the *.EXE files effective. Add the following parameter to the NET.CFG file of each workstation: signature level = [number] Replace [number] with 0, 1, 2, or 3. The default is 1. To automatically update the NETX.EXE file for all workstations, copy the NETX.EXE file to SYS:PUBLIC and add the following line to the system login script: #WSUPDATE SYS:PUBLIC\NETX.EXE ALL_LOCAL:NETX.EXE For more information on using WSUPDATE, see pages 515-519 in "NetWare Version 3.11 Utilities Reference." Windows Workstations -------------------- Copy the files listed below to the WINDOWS/SYSTEM directory of each workstation's boot disk: NETWARE.DRV VNETWARE.386 NWPOPUP.EXE VIPX.386 You can use WSUPDATE to automatically copy the new files to several workstations. For more information on using WSUPDATE, see pages 515-519 in "NetWare Version 3.11 Utilities Reference." Add the following parameter to the NET.CFG file of each workstation: signature level = [number] Replace [number] with 0, 1, 2, or 3. The default is 1. New Parameter for Windows on the Network ---------------------------------------- A new NET.CFG parameter for packet signing is available for workstations that load Windows from the network and run in enhanced (386) mode: sign 386 mode = [number] Replace [number] with 0, 1, or 2. The default is 1, which disables interrupts and preserves the 386 32-bit registers. Choose 0 to enable interrupts at this workstation. Choose 2 to force 16-bit signing at this workstation. NOTE: The new NETX shell can detect workstation type (16- or 32-bit) and automatically adjust to 16- or 32-bit code. Installing NCP Packet Signature on the OS/2 Workstations. -------------------------------------------------------------- NCP packet signature requires OS/2 version 2.0. Copy the file SECOS2.EXE (self-extracting ZIP file) to a directory on the network or your local hard drive. Change to that drive and make the direct- ory containing SECOS2.EXE your current directory. Format a high-density 5-1/4" or 3-1/2" diskette and give it a volume name of REQUESTER by using LABEL (provided with the client operating system). Run SECOS2.EXE as follows (where X: is the drive letter of the formatted REQUESTER diskette). "SECOS2 -D X:" This procedure unZIPs the update files onto the floppy diskette in the correct directory structure. Run the INSTALL program from the REQUESTER diskette and follow the instructions. Add the following parameter to the NetWare Requester area of the NET.CFG file for each workstation: signature level [number] Replace [number] with 0, 1, 2, or 3. The default is 1. Enabling Packet Burst (optional) -------------------------------- The packet burst loadable module, PBURST.NLM, must be loaded on NetWare v3.11 servers in order for NCP packet signature to work. However, using the packet burst protocol to transfer data between servers and clients is optional. Packet burst is a protocol built on top of IPX that speeds the transfer of multiple-packet NCP reads and writes. The packet burst protocol eliminates the need to sequence and acknowledge each packet. With packet burst, the server or client sends a whole set (or burst) of packets before it requires an acknowledgment. By allowing multiple packets to be acknowledged, the packet burst protocol reduces network traffic. The packet burst protocol also monitors dropped packets and retransmits only the missing packets. The NetWare server requires the PBURST.NLM to be loaded in order to transfer data in packet bursts. For a workstation to send and receive packet burst data, it requires the BNETX.EXE file and a new parameter in its NET.CFG file. NOTE: The packet burst protocol is not supported by expanded memory or extended memory workstation shells, or by OS/2 workstations. Use this procedure to enable DOS workstations to send and receive packet burst data. 1. Replace the existing workstation shell with the BNETX.EXE file. 2. Edit the NET.CFG file to include the following parameter: PB BUFFERS=x Replace x with the number of packet burst buffers. The faster the CPU, the higher the number should be. The limits are 0 to 10. Novell recommends a setting of 2. The packet burst protocol adjusts the buffers automatically for optimum performance. To disable packet burst on a workstation, omit the PB Buffers parameter from its NET.CFG file, or set the PB Buffers to 0. Changing the Signature Level for CLIB NLMs ------------------------------------------ If you are running NLMs that require access to remote servers, you will need to concern yourself with the signature level for CLIB and/or specific NLMs. The signature level for NLMs, can be viewed in a similar light to the signature level in the DOS shell -- it deals with the client-side of the NCP connection. The NLM security level correlates to the "Client Level" in the tables shown earlier in this document. NLMs that use CLIB are assigned a default NCP packet signature level of 1. The NCP signature only applies to NLMs that make NCP requests to remote servers; NLMs that make NCP requests to the local server, the server the NLM was loaded on, are not affected. For example, if you load a Print Server on a server, and this print server services print jobs residing on queues on remote file servers, and the remote file servers require packet signing, you'll need to make sure your print server is loaded with the correct signature level set. See the section titled "Packet Signature for All CLIB NLMs" below to learn how to change the default signature level, and why you'd want to. Caveats in Using CLIB v3.11d ---------------------------- The version of CLIB.NLM that is included in this release is 3.11d. Do not use CLIB v3.11d on a server running Novell's global messaging software if the NGM is version 1.0a or 1.0b. Contact Novell for a later version of NGM. If you are using NetWare for NFS version 1.2 Rev A, install patch PTF-F113 before you load CLIB. This patch is available in the NOVLIB area on NetWire, library 8, and it is called NFS113.ZIP. If this error message appears when you load the patch, the patch is unnecessary: Inverted file found, no update can be done If you are using DAL Server (DALSVR), install patch PTF-A-131 before you load CLIB. This patch is available in the NOVLIB area on NetWire, library 7, and it is called SQL30.ZIP. PATCH311.NLM ------------ You no longer need to load PATCH311.NLM if you are using CLIB v3.11d. If you are using an NLM that autoloads PATCH311.NLM, we have included a dummy version of the file. You installed it into SYS:SYSTEM when the SECSYS.EXE file was extracted. Packet Signature for All CLIB NLMs ---------------------------------- To change the packet signature level for all NLMs that use CLIB, use the following command format when you load CLIB: LOAD CLIB /L<number> Replace <number> with 0, 1, 2, or 3. The default is 1. NOTE: To make sure CLIB uses the correct signature level when it is automatically loaded by other NLMs, put the above command in the AUTOEXEC.NCF file. Packet Signature for One NLM ---------------------------- To change the packet signature level for a single NLM, use the following command format when you load the NLM: LOAD loadable_module [optional module parameters] (CLIB_OPT)/L<number> Replace <number> with 0, 1, 2, or 3. The default is 1. For example, LOAD PSERVER MYPRINTSERVERNAME (CLIB_OPT)/L3 CLIB NLM Warning ---------------------------------- Warning: If you are using the API: NWSendNCPExtensionRequest() to send to a remote server and packet level security is being used, (ie., when the packet level is being signed) the server may ABEND. If you need to use this API in development, or if an application on your server uses this API you will need to obtain the next revision of CLIB which will eliminate this problem. Large Internet Packet parameters: ---------------------------------- The security release also includes a Large Internet Packet feature which allows the server and the client to negotiate for the largest packet size across a wide area network. This service may be turned off by adding the following parameter to the NET.CFG file at the workstation: LI PACKETS=OFF This service may also be turned off at the server by using the settable parameter: SET ALLOW LIP = OFF (the default is ON). NOTE: When using SNA links, LIP should be turned off both at the client and the server. Packet Signature Considerations for Job Servers ----------------------------------------------- Network supervisors should be aware that some job servers do not support NCP packet signature. A job server may produce unsigned sessions if: * It does not operate on top of DOS * It does not use standard NetWare shells * It is not an NLM * It uses its own implementation of the NCP engine (such as embedded print servers in printers). Minimizing Risks ---------------- To minimize security risks associated with job servers: * Install queues only on servers with signature level 3. * Do not allow privileged users to put jobs in queues on servers with signature levels below 3. * Make sure the job server's account is unprivileged. * Disable the job server's ability to change to client rights. Disabling Change to Client Rights --------------------------------- To prevent a job server from assuming the rights of a client, put the following new SET command in the server's AUTOEXEC.NCF file: SET Allow Change to Client Rights = OFF The default is ON, because certain job servers and third-party applications cannot function without changing to client rights. For customers using NetWare Name Service (NNS). ---------------------------------------------------------- The current version of NNS does not support the NCP Packet signature security enhancement. Novell will be providing an updated release of NNS in the near future that will support NCP Packet signatures. Customers running NNS and wishing to apply the packet signature security enhancement to servers in the NNS Namespace Domain must first apply the NNS update when it becomes available. Servers that are not in the NNS Namespace domain are not effected, therefore, the security enhancement can be applied to any servers that are not in the NNS Namespace Domain. Troubleshooting Tips -------------------- This section describes some solutions to problems that may be associated with using NCP packet signatures. Clients Cannot Log In --------------------- Make sure the old *.COM shells are renamed or removed from the directory where the new *.EXE shells reside. Make sure the packet signature levels on the server and the client are correct. The following situations do not allow logging in: * Server packet signature = 3, client signature = 0 * Server packet signature = 0, client signature = 3 * Utilities are old and do not support packet signature * Shells or requesters are old and do not support packet signature "Error Receiving From the NetWork" Appears ------------------------------------------ The client is using an old utility, such as LOGIN.EXE file that does not include NCP packet signature. Make sure the new LOGIN.EXE and other new utilities are installed on all servers on the network. Third-party NLMs Do Not Work ---------------------------- If the SET parameter Allow Change to Client Rights is turned OFF, some third-party NLMs may not function. Turn this parameter ON. Unsecure Clients Log In to Secure Server ---------------------------------------- The clients are using an old LOGIN.EXE file that does not include NCP packet signature. Set the sever security level to 3 and make sure the new LOGIN.EXE and other new utilities are installed on all servers on the network. Add a preferred server statement to the NET.CFG file for all clients that have access to secure servers (level 3). Network Security Guidelines --------------------------- In addition to installing NCP packet signature, network supervisors can use other NetWare security features and protective measures to keep their network data secure. The following security guidelines are suggested: * Use only the most current versions of system software, client software, and patches. * Regularly check for viruses. * Use the SECURITY utility to detect vulnerable access points to the server. * Lock NetWare servers in a secure room. * Issue the SECURE CONSOLE command from the NetWare console. The system will only load NLMs from SYS:SYSTEM. * Select "Lock File Server Console" from the MONITOR main menu when the NetWare console is not in use. * Always use a password different from the SUPERVISOR password for RCONSOLE. * Limit the number of users with SUPERVISOR rights. * Log in as SUPERVISOR as little as possible. * Use access control features in NetWare to limit users to necessary applications and data. * Enable intruder detection and lockout. * Advise users to log out when their workstations are unattended. * Secure unattended workstations. * Require passwords of at least five characters on all accounts. * Force password changes at least every three months. * Require unique passwords. * Limit the number of grace logins. * Limit concurrent connections. * Enforce LOGIN time restrictions and station restrictions. * Train users and administrators on the use of NetWare security features. NCP Packet Signature for NetWare v3.11 PATENT PENDING - Novell, Inc.